前言

昨天我們實作了 Cookie + Session Authentication，體驗到「伺服器會記住使用者狀態」，用從設定，到測試，會發現程式不用寫太多，資料都會記在瀏覽器裡面，使用起來很方便。

但問題來了：

• 如果有 上萬個使用者同時登入，伺服器要記住上萬個 Session，記憶體壓力會很大。
• 如果系統是 分散式架構（多台伺服器），不同伺服器之間要共享 Session（通常需要 Redis 或資料庫同步）。

這些問題在大型系統裡非常常見，於是工程師們開始思考：

能不能把「使用者狀態」交給用戶端自己保存，而不是伺服器？

這就是 Token Authentication 的起點。

Token Authentication 的基本概念

Token（憑證）是一串伺服器簽發的「隨機字串」或「加密字串」。

1. 使用者登入成功 → 伺服器產生一個 Token。

2. Token 傳給用戶端（瀏覽器 / App）。

3. 用戶端每次呼叫 API，都在 Header 帶上 Token：

   Authorization: Bearer <token>
   

4. 伺服器驗證 Token 是否有效，通過就放行。

當你了解了Token的機制，第一件事情一定是拿來跟Session比較，那我們也來弄成一個表格給大家參考：

Token vs Session 的比較

簡單來說：Session Authentication 就是讓伺服器記住你，而Token Authentication 則是讓你自己帶證明。

用比較生活的比喻，Session 像是去餐廳用餐，服務生會幫你「記住」桌號，每次點菜只要報桌號即可。而Token 像是演唱會入場券，票上有你的座位資訊，每次進場都要出示票，場館不用特別記錄你。當然，一個機制有優點，一定就會有缺點，讓我們來詳細的分析一下：

Token 的優點

1. Stateless（無狀態）
   • 伺服器不需要存使用者狀態，減少記憶體壓力。
   • 每個 API 請求都可以被任意伺服器處理。
2. 適合分散式架構
   • 多台伺服器不需要共享 Session，任何一台伺服器只要能驗證 Token，就能處理請求。
3. 跨平台方便
   • Token 可以存放在手機、前端、IoT 裝置上，用於 API 呼叫。

Token 的缺點

1. 無法主動失效
   • 一旦發出去的 Token，只要還沒過期，就能一直使用。
   • 使用者登出時，Token 不會自動失效（除非有黑名單機制）。
2. 需要設計 Token 的結構與安全性
   • Token 太簡單 → 容易被偽造。
   • Token 太複雜 → 驗證成本高。

在這裡大家可能還是有點不理解，什麼是「沒過期就能一直使用」，這邊需要解釋一下，Token裡面會有著有效期限，但如果在過程中，有人盜用了這個Token，我們也馬上知道了，卻沒有辦法阻止驗證，因為Token是使用者自帶，Server端只負責解密，確認有辦法解出來，角色有這些權限。

所以後來出現了 JWT（JSON Web Token） —— 一種「自帶資訊」又能驗證真假的 Token 格式。

總結

• Session Authentication：伺服器記住你，靠 JSESSIONID 辨識。
• Token Authentication：伺服器不記憶狀態，用戶端自己帶 Token，伺服器驗證即可。
• Token 的優點是 無狀態、適合分散式、跨平台方便，缺點是 無法主動失效。

今天就到這裡，明天，我們會示範無狀態請求的運作方式：

• 先用最簡單的方式模擬「每次 API 都要自己帶帳密」。
• 然後進一步解釋為什麼要有「自帶資訊的 Token」，從這個概念中引導出資安下一步重要觀念:JWT。

明天見！